Re: Semantic tags

Wouldn't it be OK to make assertions about other people's resources if you coined URIs for those resources in your own domain and then asserted owl:sameAs?

I guess it's not clear what "context-dependent class" means.

On Apr 20, 2015, at 11:11 PM, Robert Sanderson <azaroth42@gmail.com<mailto:azaroth42@gmail.com>> wrote:


Hi Jeff,

By "knowledge graph", I just meant the global graph of RDF statements. We shouldn't be making assertions (such as adding spurious, context-dependent classes) about other people's resources.

Apologies for the confusion!

Rob


On Mon, Apr 20, 2015 at 6:42 PM, Young,Jeff (OR) <jyoung@oclc.org<mailto:jyoung@oclc.org>> wrote:
So annotation graphs are objectively distinct from knowledge graphs?

What is the distinction? Aren't all RDF descriptions a subjective annotation of reality? Is this a Turing test?

On Apr 20, 2015, at 9:22 PM, Robert Sanderson <azaroth42@gmail.com<mailto:azaroth42@gmail.com>> wrote:



Hi Antoine, all,

To summarize the requirements:

1 Use a URI as a tag for a resource, rather than a string that is likely to be ambiguous
2 Allow both the concept described in a referenced document, and the concept itself as the tag
3 Do not pollute the knowledge graph about the concepts or documents by specifying annotation-specific information about them
4 Must work with multiple bodies, and multiple motivations


And the options:

* Add a class or property to the concept URI, as per oa:SemanticTag in the CG draft.
  -- Bad as it breaks 3, prompting the change from the CG structure

* Have a new predicate between annotation and resource as subProperty of hasBody
  -- Bad as now clients need to look in multiple places for tags versus semantic tags,
    Also sets a bad precedent for communities to do the same, making finding the body of an Annotation much harder in general.  It would mean generating new contexts for every community that did this, compared to minting new motivations which go in the value in the JSON rather than the key.

* Add a class or property to the annotation, such as the SemanticTagging motivation
  -- bad as it breaks 4 (as discussed)

Meaning we need some sort of reified intermediary node:

* Have an intermediary node as a SpecificResource with the tagging motivation
   -- Inconsistent between tags (direct body) and semantic tag (referenced from SR) without making easy things hard, which we should avoid.

* Include an intermediary Tag node for semantic tags, and relate the Tag node to the concept.
   -- Current model


The strengths of the current model are:
  * it's consistent for literal Tags and the two variants of Semantic Tag
    There's a resource, which has either a string literal (Tag with rdf:value) or a URI (Tag with foaf:page or skos:exactMatch)
  * it doesn't break any of the requirements
  * if copied, it doesn't mean new contexts all the time
  * it doesn't encourage proliferation of predicates

We could even dispense with the current SemanticTag class and just let clients introspect on the properties to figure out which type it is, but I don't see any harm in distinguishing the two as we currently do.  I'm certainly open to any sort of streamlining that can be done.

So I unless there's a solution I'm missing, I feel like we have the best option at the moment.  Proposals are very welcome, of course!

Rob



On Mon, Apr 20, 2015 at 11:56 AM, Antoine Isaac <aisaac@few.vu.nl<mailto:aisaac@few.vu.nl>> wrote:
Hi Rob,

Sorry for taking so long to answer...
I'll just focus on the semantic tag issue.

Indeed the solution I had dug up ('semantic tagging' motivation) would not work well with annotations with several bodies of different types.

I'm not sure I buy the solution with the SpecificResource. As you say it still has one level of indirection, so it won't solve my worry.

Perhaps the one thing that would solve it would be to use a specific sub-property of oa:hasBody to indicate that the target is a semantic type (i.e. oa:hasSemanticBody). It was also considered a couple of years ago... and discarded, probably (I don't remember for sure) because it introduces heterogeneity to the core pattern of the Annotation data.
That being said, the solution with the blank node also breaks the pattern, big time. One expects to find something useful as the object of the oa:hasBody triple, but it's not really there: one now to make specific rules to go one step beyond, for the case of semantic tags...
Though I reckon that for the JSON-LD serialization it may be less harmful than the sub-property trick.


At this point I must apologize for playing the devil's advocate and testing these old options again on you.
As you've read I've been quite surprised (and displeased) with the new semantic tagging pattern. And maybe it's good if the new WA spec can claim to have considered all alternatives (and we're actually doing it quite quickly here, at least way quicker than in the OA times!)

Cheers,

Antoine

On 4/3/15 7:10 PM, Robert Sanderson wrote:

Hi Antoine,


On Fri, Apr 3, 2015 at 5:52 PM, Antoine Isaac <aisaac@few.vu.nl<mailto:aisaac@few.vu.nl> <mailto:aisaac@few.vu.nl<mailto:aisaac@few.vu.nl>>> wrote:

        The reasoning was that we didn't want to add a class (oa:SemanticTag) to any arbitrary non-information resource on the semantic web just because it was currently being used in that role for the annotation.  Eventually all resources would have the class and it would be worthless.  So the indirection is to solve that problem.


    Well, I'd consider this not to be a big problem anyway...


It does seem unlikely to break things, but we shouldn't be specifying bad behavior when there's a consistent pattern that fixes it.

    But maybe a solution could be to remove this type altogether?
    I think we had discussed it a couple of years ago for Open Annotation, hadn't we?
    An  alternative would be to use another feature, for example an attribute of the Annotation itself, maybe a specific motivation (say, oa:semanticTagging as a skos:narrower of oa:tagging).


This wouldn't work in the case when there are multiple bodies, one of which is an external comment resource and the other a semantic tag. You wouldn't know which was which.

So you'd still need a level of indirection, but it might be more consistent with issue #11 (on github) if the motivation was attached to a SpecificResource than a new class of SemanticTag.

On the other hand it would be less consistent with regular Tags unless we also changed that structure to the much more cumbersome:

_:anno1 a oa:Annotation ;
   oa:hasBody _:spec1 ;
   oa:hasTarget <target-uri> .

_:spec1 a oa:SpecificResource ;
   oa:motivatedBy oa:tagging ;
   oa:hasSource _:tag1 .

_:tag1 a oa:EmbeddedContent ;
   rdf:value "tag" .


Thoughts?

    At the time of the original OA design, this other feature might have been discarded because typing the body (which was a the concept then) as oa:SemanticTag was a simple thing to do.  But if now we have the choice between introducing a specific motivation at the Annotation level or the indirection, I would go for the specific motivation...



             - why skos:related? Given the sort of semantic tagging scenarios we (and I believe anyone else) have, the link is much stronger from a semantic perspective. I'd have expected skos:exactMatch.

        A good question, and one that I don't find the answer to immediately.  I think that exactMatch could be used instead of related, which does seem a much weaker statement.  The intended semantics of the relationship are similar to that of foaf:page, but instead the object is the concept directly.  Happy to go with your opinion on which predicate makes most sense there!


    Yes skos:exactMatch seems fine. Better, in any case!


Created issue #29 to do this, and will close if we move to a model along the lines of above.
Thanks!

Rob

--
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305



--
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305



--
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305