You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the construction of uris in social, gmane and participation packages have many subtleties sorted out in code.
Of these, one remained until now: the uris of individuals for the most important entities should have the snapshotid in it or not?
Cons of using the snapshotid in the uris: the uri gets larger (and so the final data). Same entities are not directly related if they are present in different snapshots (they have to be related through IDs).
Pros of using the snapshotid in the uris: data from each snapshot does not get mixed. For example, a twitter user can have different screennames in different snapshots. The information about which snapshot each screenname is related to is lost in the final linked data.
This last difficulty can be overcome by the use of named graphs (alias "conjunctive graph contexts") and the RDF link between the instances and the snapshoturi.
Support for named graphs has some drawbacks in real usages,
such as the current inability in Fuseki/Jena for creating new named graphs on the fly and reasoning about them (the reasoner has to be loaded at startup for each graph).
The currently adopted "solution" is not to use the snapshotid in the uris.
The text was updated successfully, but these errors were encountered:
ttm
changed the title
define uri convention
define uri standard
Feb 12, 2016
the construction of uris in social, gmane and participation packages have many subtleties sorted out in code.
Of these, one remained until now: the uris of individuals for the most important entities should have the snapshotid in it or not?
Cons of using the snapshotid in the uris: the uri gets larger (and so the final data). Same entities are not directly related if they are present in different snapshots (they have to be related through IDs).
Pros of using the snapshotid in the uris: data from each snapshot does not get mixed. For example, a twitter user can have different screennames in different snapshots. The information about which snapshot each screenname is related to is lost in the final linked data.
This last difficulty can be overcome by the use of named graphs (alias "conjunctive graph contexts") and the RDF link between the instances and the snapshoturi.
Support for named graphs has some drawbacks in real usages,
such as the current inability in Fuseki/Jena for creating new named graphs on the fly and reasoning about them (the reasoner has to be loaded at startup for each graph).
The currently adopted "solution" is not to use the snapshotid in the uris.
The text was updated successfully, but these errors were encountered: