Re: owl:sameAs - Is it used in a right way?

Hi Pat,

Most users will interact with what the repository manager knows was
either the most recently updated or the manually set "current"
version. Queries are setup to use the current version by default.
However, part of my projects requirements are to allow the consistent
querying and access to the exact published statements from
publications while allowing changes as necessary. If the set of
statements have been updated since they were published, then this
requires fine-grained control over which versions are applicable to a
given query.

An IRI and its basis in RDF theory does not allow a user to directly
specify what version they are referring to. Hence, various people have
implemented it separately, as you mention, which is always prone to
interoperability concerns, but this is no more than any mutable RDF
dataset whose overall interpretation may change over time.

In terms of resolving the IRIs, the usual IRI for any item will
resolve (using content negotiation) to the current Graph. They can use
the specific version IRI for the Graph if they are aware of it to
resolve to the version containing their desired statements.

If users request documents in a Quads format (N-Quads, TriG, RDF/JSON
(with graph extension), JSON-LD etc.) they see the version IRI as the
graph, so they can get back to the version they are looking at
(without having to look for the OWL Version IRI which in this project
is always present anyway).

If a user requests two different versions and decides to merge them
together into a single Graph then it is on their head. There are more
serious implications than RDF IRI stability at that point, as there
may be internal contradictions with updated statements sitting beside
their old values without being removed by the merge. If on the other
hand they request two versions and do not merge them, labelling them
either with their version IRIs or some other distinct identifier, they
are free to compare and contrast between the two Graph's in a
systematic way.

I have also implemented a completely different pattern for the context
parameter in Quads formats in the Bio2RDF web application, where the
context currently specifies which internally defined provider a
statement originated from. Providers do not necessarily have a
one-to-one relationship with either versions of datasets, datasets as
a whole, or actual physical providers, particularly in cases where
statements are synthetically created.

I can understand why RDF does not venture to provide any meaning for
Graphs as there are various conflicting patterns of use. For example,
in the Bio2RDF provider pattern all of the statements resolved for a
single document should be able to be merged, although other users may
wish to eliminate statements from particular providers for any number
of reasons, and they are free to do that if they request Quads
formats. Quads formats are very useful for practical data management
so I am glad that they exist.

Cheers,

Peter

On 18 March 2013 14:16, Pat Hayes <phayes@ihmc.us> wrote:
> Peter, greetings.
>
> I know you can do the graph-as-context trick you describe, and you are not alone. This style of using RDF does however directly violate the RDF specifications, and so is not conformant. So there is a risk of your content being misused and misunderstood by RDF users who are unaware of your extra-RDF conventions for keeping contexts separate.
>
> Pat Hayes
>
> On Mar 17, 2013, at 10:45 PM, Peter Ansell wrote:
>
>> On 18 March 2013 12:50, Pat Hayes <phayes@ihmc.us> wrote:
>>>
>>> On Mar 17, 2013, at 6:22 PM, Peter Ansell wrote:
>>>
>>>> On 18 March 2013 09:14, Alan Ruttenberg <alanruttenberg@gmail.com> wrote:
>>>>> Can someone *please* tell me what a context is??
>>>>>
>>>>> My null hypothesis is that when someone says "context" they either don't
>>>>> know what they are talking about, or are too lazy to say. Both these cases
>>>>> are deadly for clear communication on the web.
>>>>>
>>>>
>>>> One interpretation may be RDF Graphs, see RDF-1.1 drafts for the
>>>> current definition of that [1].
>>>
>>> Nope, RDF graphs do not, according to the current (and likely future) specs, define contexts (in any useful sense), because they cannot change the interpretations of IRIs.
>>
>> The WebArch document (rather hopefully) assigns complete
>> responsibility for assigning the intended interpretation of an IRI to
>> the owner (based on the IRI scheme). This is not how names are
>> traditionally defined and refined in science, so there is a
>> fundamental clash between the two philosophies there.
>>
>> Even if one would theoretically agree that the broad intended meaning
>> for an IRI is not changing, there are very simple ways to implement
>> context-sensitive queries using different RDF graphs. Different RDF
>> Graphs can be used for the same query to contrast the differences
>> across either time or some other dimension where differences in the
>> statements related to an IRI changes the exact interpretation of the
>> IRI. Personally I use owl:versionIRI for the version (read context)
>> identification but there are certainly other ways to identify context
>> and simply map the context to RDF Graphs. This makes for a simple to
>> manage system that matches my groups intended semantics when a
>> scientist updates the dataset. Ie, the version changes and one may
>> choose to use a previous version (where the version is identified as
>> an IRI which maps directly to an RDF Graph) if it is necessary, but
>> IRIs are consistent across most updates to make the process
>> manageable.
>>
>> Cheers,
>>
>> Peter
>>
>>
>
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>

Received on Monday, 18 March 2013 05:23:17 UTC